Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/[e-mail] _Mon Nov 23 11:41:11 1992.msg

Internet Message Format | 1994-01-24 | 4KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA13554; Mon, 23 Nov 92 11:41:11 MET
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
    id AA06973; Mon, 23 Nov 92 11:53:34 +0100
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 23 Nov 92 10:51:36 GMT
Received: by manuel.hpl.hp.com
    (16.6/15.6+ISC) id AA12224; Mon, 23 Nov 92 10:51:29 GMT
From: Dave_Raggett <[e-mail]>
Message-Id: <[e-mail]>
Subject: Different forms of Annotations
To: [e-mail]
Date: Mon, 23 Nov 92 10:51:26 GMT
Cc: [e-mail]
Mailer: Elm [revision: 66.25]

It seems to me that there are several flavours of useful annotations:

News style "responses"     (similar to Dan Connolly's suggestion)
======================

Here people can post responses to documents. This could be restricted to
a special class of discussion documents or it could be completely open
mechanism allowing responses to any document.

You would read the original document and then compose a response (as an
ordinary html document). The response is then notified to the server owning
the original document. The notification is either a copy of the response
document or a http-like reference to it.

When people next read the original document, the browser shows that a response
has been posted. This is read by clicking the "view next response" button
which could be part of the browser's user interface or a link in the document.

If the server had write permission it could modify the original document to
include a link to the list of responses. By using a hidden link, i.e. a
different tag than <A>, the browser could indicate that the document had
one or more responses, without regard to where they are placed in the
documents text itself.

In my opinion, a better approach is for the server to keep a directory of
which documents have responses, and to add the information dynamically when
sending the original document (caching could be used to avoid the directory
look-up penalty for popular documents). The response info could be sent as
part of the document or via additional parameters.

This mechanism works even when the server doesn't have write access, and can
take advantage of broadcast protocols like news. Dan's suggestion is fine in
the short term, but I think we need to think about this in more depth,
without restricting ourselves to using only the current protocol
infrastructure. I am particularly enamoured by ANSA's trading mechanism as a
means of managing the caching of documents and responses, but haven't the time
to elaborate on this right now.

One thing we should consider ASAP is to include details of document creation
or last  modification date/time. This is essential for purging/refreshing
cache information. I also think it would be a good idea to include the
requestors identity in the request formats sent to servers, going beyond the
internet address info. This would be really helpful for supporting
closed-readership groups.

Direct Annotations (Post Its)
=============================

These are notes which appear in place when you read the original document,
although in some cases you might need to click on a postIt button to see the
actual note which then appears as a pop-up (pale yellow?) window. These may
be penned handwritten comments, or short voice annotations. I can easily
imagine people wanting to using conventional proof-reading marks.

The annotations are attached to anchors within documents - either
pre-existing anchors or via pattern matching. In either approach problems may
occur when the original document is modified. A heuristic pattern maching
approach would be reasonably insensitive to insertions and small changes in
the region of attachment - you don't need an absolute match!

This flavour of annotations can be managed in a simlar way to the previous
style.

General Revision Histories
==========================

A third flavour of annotions, is to keep a revision history of changes to
documents. A check-out/check-in mechanism can be used to avoid the need for a
branching structure caused by people independently modifying the same version.


Dave Raggett,

HP Labs, Bristol, UK   ([e-mail]) [phone]